home *** CD-ROM | disk | FTP | other *** search
- Things remaining to be done to ispell:
-
- - The "munchlist" script can actually increase the size of a
- dictionary. For example, munching dict.191 (after my bug fixes
- to it) reduced the number of words by about 40, but increased
- the number of characters by a small percentage. This is
- because munchlist doesn't recognize duplicate suffixes that
- generate the same result, except for the three special
- "s-ending" suffixes J, Z, and X. For example, right now
- munchlist will make BATHER by adding the R suffix to both
- BATH and BATHE. It would be nice if munchlist could recognize
- the redundancy and reduce its output so that each word was made
- in only one way.
- - The characters in the -w option should be written to the header
- of the hash file, and to a header in the personal dictionary,
- so the user doesn't have to remember to specify them every time.
- - Buildhash should support the -w option.
- - Buildhash, munchlist, icombine, and the expand scripts should use
- a character other than slash for the flag separator, so that slashes
- are available to the -w option. I tend to lean towards commas.
- - It might be nice to support multiple personal dictionaries. On
- the other hand, it's pretty easy to combine them with "cat".
- - Good.c should be table-driven, so that it is easier to modify for
- other languages. Ideally, it would support prefixes as well.
- - A small amount of string space could be saved if buildhash would
- combine strings with common suffixes (e.g., "and" could be stored
- as a pointer to the tail of "bland").
- - (Peter Wan) Ispell should have a "server mode" for large sites, to
- get rid of the time needed to read in the dictionary. On System V,
- this could be accomplished by having the first execution of ispell
- read the dictionary into a shared-memory region. Later incarnations
- would then get the dictionary by just attaching to the region.
- One problem would be that the dictionary gets modified during
- the run, so you might still have to do a memory-to-memory copy
- after the attach. The size of having two copies of the dictionary
- might prohibit this on many machines. Another approach is a
- message-based "good.c server", but this too would have to deal
- with the possibility of modifiying the dictionary.
-